Technical Lead Manager

Read this first You're probably already doing most of this job without the title. People bring designs to you before they build, your review is the one that catches things, and when something breaks late at night you're on the thread whether or not you're on-call. Juniors ask you about their careers even though nobody made that your job. What we'd like to add is a team that's actually yours, a real say in who joins it, and the authority to decide how your part of the system gets built. TLM is the step before Engineering Manager and we'd rather say that plainly than pretend otherwise. In 12 to 18 months you're either running a bigger team as an EM or you've worked out that you'd rather go deep, in which case Staff and Principal are open. Either way you won't be stuck.

You'll build the AI connector framework. The system that generates connectors, tests them, and repairs them on its own when a source system changes underneath.

AI runs through every workflow, not just the product. Design, review, testing, production debugging. Teaching your team to work this way is part of the job.

Real scale behind it. 100 billion records and petabytes of data every month, 2,000+ customers, and 150+ source systems that change their APIs without warning.

The day job changes. Your engineers write specifications, evaluations and guardrails as much as application code, and you'll be judging output that isn't fully predictable. Few engineers in India are paid to do this yet.

Platform services and database connectors that carry real weight. You'll lead the development of highly scalable, reliable and secure platform services and database connectors that power mission-critical data pipelines for thousands of enterprise customers. When a connector breaks, someone's revenue reporting is wrong that morning and they know it.

Pipelines into the modern data stack. These pipelines connect to warehouses like Snowflake, BigQuery and Databricks, as well as data lakes like Apache Iceberg. Each destination has its own semantics, its own failure behaviour and its own performance envelope, and your team owns getting all of them right.

Observability, reliability, security and auditability as defaults. These get embedded into everything your team ships rather than bolted on when a customer asks. You set that standard and you hold the line on it.

The hard problems underneath. Exactly-once delivery when any component can fail. Multi-tenancy where one customer's load never touches another's. Schema changes arriving mid-flight from a source system that gave no notice. None of these get solved once.

You get to decide. Architecture in your area, what the framework does and doesn't do, where AI is the right tool and where it honestly isn't, and the hiring bar for your team. You won't be writing recommendations and waiting for someone else to approve them.

Your scope grows as fast as the company does. Engineering is up 30 percent in the last four to five months and that continues. Start with five engineers and you'll be running a considerably bigger team by the time you're done. That isn't on offer at a company standing still.

You get direct access to engineering leadership. No manager three levels down carrying your work upward. You'll be in the room when the calls get made, which is the fastest way to learn how to make them yourself.

You don't have to stop writing code. Roughly 60 percent of your week stays technical. Nobody here is going to quietly take the code away from you over four quarters.

You'll learn something most engineers can't yet. How to run a team where AI is embedded in the work rather than sitting next to it. In two years that will be expected of every engineering leader, and most people will pick it up late and secondhand.

The framework is generating production connectors, and the quality bar is set by evaluations you designed

Shipping a new connector takes a fraction of the time it does today, and you can prove it with a number

You've hired two or three engineers yourself and they're shipping

At least one person on your team has been promoted

8+ years on backend or distributed systems

At least a year leading a team, and it doesn't have to have been official. If you're already the person everyone goes to, that counts

You've run something in production and been there when it broke. On-call, incidents, SLAs

Strong Java or another JVM language, with Kafka and Kubernetes in production

Real experience with multi-tenant systems, high availability, or data at volume

You've built something with LLMs rather than just used a coding assistant. Agents, evaluations, retrieval, prompt systems in production, any of it

You can explain a complicated system to someone who isn't an engineer

You've given someone hard feedback and kept the relationship afterwards

laptop-ats-crawler v2