Engineering Lead

About the role

You will own a few of Finrep's product lines outright: the architecture behind them, the two to four engineers building them, and the quality of what reaches customers.

The stack is Python and Go services on Kubernetes, a Next.js frontend, and pipelines that move filings, XBRL, and documents at volume. You make the calls on how those pieces fit, and you are still writing code most weeks.

You also set how this team builds. We use AI heavily in our own development, and we want someone with a real point of view on where that helps, where it quietly costs you, and what has to be true before an agent's output merges.

The bar: Our users are SEC reporting leads, controllers, and audit partners. A wrong number can reach a filing, so every change gets checked against source data and the failure cases we already know about.

Why this role

What you will do

• Own the architecture behind your product lines: service boundaries, the contracts between them, how they degrade under failure, and what reaches customers
• Manage two to four engineers: set direction, review code, give feedback that lands, and settle the technical disagreements the team cannot
• Design the retrieval and agent pipelines behind our reporting workflows, and the evals that keep them honest as models and prompts change
• Make the scaling calls on data: filings, XBRL, and document pipelines where a slow query becomes a support ticket
• Own production reliability for your services: Kubernetes, CI/CD, instrumentation, incident response, and the fixes that follow
• Define how this team builds with AI: what agents write, what a human reviews, what a test has to prove before anything merges
• Hire and ramp engineers as the team grows

What we are looking for

• 4-6 years building production software, with 1-3 years leading or mentoring engineers, formally or not
• Strong production Python. Go is a plus, or show us a new language you picked up and shipped production code in
• Shipped an LLM-backed system that real users depend on, and measured whether it got better
• Owned a service in production: designed it, ran it, and been on the hook when it broke
• Current enough technically to lead a design review and make the call when the team is split
• You build with AI tooling daily and have a real opinion on where it belongs in the SDLC and where it does not
• Clear written communication. You can explain a tradeoff to someone who is not an engineer

What adds a bonus

• Go in production
• Kubernetes on AWS, Azure, or GCP at meaningful scale
• Data pipelines or storage at a volume where design shows up in the latency graph and the bill
• Retrieval systems, evals, or agent orchestration running at scale
• Took a product from its first customer through repeated releases
• Internal tooling or an SDK that other engineers actually adopted
• Open source, or a write-up of a system you built and the decisions behind it

What this is not

• Not a management track away from code. You will write code most weeks
• Not a role with an architecture handed to you. You propose it, then defend it
• Not a place to learn distributed systems from scratch. You need prior experience with partial failures, retries, and data consistency