How We Build
We don’t run sprints. Our company prioritizes the work together, and Engineers work in cross-functional pods. We leverage AI to draft most of our tickets, and Engineers write some of their own. There is no process layer standing between an idea and the code. That model moves fast, and it is only as good as the context feeding it. A confident, well-structured ticket that is wrong about how insurance requirements vary by trade can be painful. This role’s north star is to fix that.
You are not here to assign work or gate it, you're are here to make sure the right work is the easiest work to pick up. Your influence comes entirely from the quality of your context and the clarity of your case, which is either the best part of this job or the wrong job for you.
The domain has depth and complexity. Insurance requirements vary by trade, scope of work, and state. Compliance rules vary by customer. You will not be able to reason about our data without learning the domain, but don't worry - we'll give you time to learn it.
What you'll do
1. Context & Documentation
- If AI drafts the tickets, the quality of what gets built is decided by the context it receives. That context is what you’ll optimize.
- Understand and write down how the platform actually behaves today - the workflows, the exception paths, the rules, and the undocumented behavior currently living in people's heads.
- Build and maintain the reference material that our AI tooling and our engineers pull from, and keep it accurate as the product changes. Stale documentation now produces bad tickets and bad code automatically, at scale.
- Review tickets and specs against reality before anyone builds them. This is the part that matters most: AI-generated work is confidently wrong exactly where it costs the most - edge cases, compliance rules, customer-specific commitments, anything that is not in the repo or the training data.
- Capture acceptance criteria, edge cases, failure behavior, and explicit non-goals so a pod can pick something up and build it without a meeting.
2. Product Data & Analysis
- You’ll answer product questions with SQL against real data. Things like usage, throughput, drop-off, exception rates, workflow completion, turnaround times.
- Quantify shipped work. Did it move the number it was supposed to move, and by how much.
- Build and maintain the recurring reporting the pods rely on, so nobody rebuilds the same query every month.
- Surface what nobody asked about. Note the distribution, the outliers, and the pla